The present invention relates in general to the display of messages, and particularly error or fault messages, from a plurality of user applications in data processing (processes) which are running in parallel with one another. It relates in particular to the display of messages of this kind which call for action by the user. Specifically, the present invention relates to a method which makes it possible for the messages from processes running in background to be displayed in such a way that the user is not forced to interrupt the work he is doing at that moment.
In the multitasking operating systems which are in widespread use at the present time it is normal for many processes to be running virtually in parallel one beside the other. Even user applications take advantage of this capability. Whereas formerly it was quite normal to exit an application before starting another one, today one jumps straight back and forth between different applications which are running in parallel. The changeover in this case is made either by pressing a key combination (e.g. Alt-Tab in Windows) or by clicking with the mouse on the desired application window or on the representation of the application on a shortcut bar or the like.
What are normally used to display errors or to ask the user for additional information are message boxes, which in each case are shown in foreground. These are generally designed to act as modal boxes, i.e. the window showing the particular application is frozen (i.e. is made inactive) until the user has reacted to the message shown in the message box concerned. This seems sensible enough when the user is given a message which relates directly to the process which is actually active at the time when the message is given but if the message originates from a process which is running in background then the user is forced to interrupt the work he is currently doing.
In more complex environments where the processes in background are actually playing an active role and are not simply waiting for fresh inputs from the user or are not deactivated, then the user may very easily be confused if the work that he is doing in an application (e.g. typing in a text in a word-processing application) is interrupted in this way by an error message from a process running in background. True, it is important to the user that messages which call for action, and in some cases immediate action, on his part should be shown to him at once, but there are nevertheless further disadvantages when the application window which is active at the time is automatically frozen or made inactive when the relevant message is shown, namely:
1. Where necessary, the user may have to establish which application generated the error, and may then have to activate it and remedy the error. Hence he is forcibly distracted from the work he is currently doing and later on he may even find trouble in dropping back at the exact spot where he had to break off.
2. If an error message pops up suddenly, it can easily happen that it is accidentally acknowledged and thus cancelled again, such as by pressing the return key in the course of typing in text. The only way the user can then find the source of the error message, if indeed he can do so at all, is by a laborious search through all the applications which are running.
3. Generally speaking, the only way in which an application can tell the user what its status is is by means of a message box or directly in one of the application windows, e.g. on a status bar. The disadvantage which this has is either that the work the user is doing is interrupted or that it may in certain circumstances be a considerable time before the user learns the details of the change in the status of the process that generated the error, the reason being that he first has to bring the process into foreground (activate it) before he can check its status.
If one then considers not a simple environment such as the xe2x80x9cnormalxe2x80x9d use of a modern-day PC but more complex business processes, then the problems described above become even more acute.
As already indicated, it is standard practice nowadays for message boxes to be shown in the fore round of the screen when an application wants to ask the user for information or display an error message or some other message. Showing the status of a process as well as showing messages, etc. is normally achieved in a way specific to each individual software program or function, generally by showing the status on a status bar in a part of the main window. In Lotus Notes for example the fact that a network transfer is taking place is indicated by a lightningflash symbol in the bottom left-hand corner of the window. Another example is the hourglass symbol which is shown (in Windows for example) when a given function is running and the user cannot perform any inputs.
To save detailed error or fault information so that the error or fault can be traced, it is possible for messages to be written to a central log. A typical representative of logs of this type is for example the Windows NT event log. The user can employ a special program to call up this log and analyse the error message or messages contained in it. However, even with this facility, it is still usual for a message box to be displayed as well, at least when the faults are serious ones (e.g. xe2x80x9cSystem service could not be startedxe2x80x9d for example when system services could not be started under Windows NT). This message box then makes the active window inactive until the user has acknowledged the message. It is also normal for a message box to be displayed to tell him that there are in fact error messages in the event log (see FIG .1).
FIG. 1 shows an example to illustrate the situation which may be confusing to a user where a plurality of message boxes 4 appear simultaneously. The applications running are 1, 2 and 3 and it is the window for application 2 which is active at the moment.
It is also known for application-specific messages to be exchanged between a plurality of programs by so-called message queueing. What this means is that the messages are placed in queues (enqueued) and are called up again from the queues for interrogation (dequeued). This being so, the applications which communicate with one another via the queues do not necessarily have to be running simultaneously. The queues are named objects in which messages from a given application are stored and from which they can later be called up by a different application. The queues are managed by a so-called queue manager, which is a system program which makes the message queueing facility available to the applications. The message queueing facility itself however serves only to transfer messages between different programs. The information is still displayed, and the program or process states are still monitored, in ways specific to the application.
The object of the invention is therefore to provide a method which makes it possible for messages and/or error information from a process which is active in foreground to be shown directly to a user and for messages from a process running in background which call for interaction with the user to be shown in foreground in such a way that the user is not forced to interrupt the work he is doing in the application running in foreground.
This object is achieved by the method described in claim 1.
Other advantageous embodiments of the method according to the invention are described in the subclaims.